ちょっと待ってください!あなたが使うべきは本当にT系インスタンスですか!?
はじめに
おはようございます､加藤です｡EC2には様々なインスタンスタイプがありますね｡初めてAWSを触る方は､汎用向けであるM系かT系を利用する事が多いのでは無いでしょうか? M系とT系の価格とスペックを比較した表を下記に用意しました｡
| インスタンスタイプ | vCPU | メモリ[GiB] | 料金(東京)[USD/時間] |
|---|---|---|---|
| t3.large | 2 | 8 | 0.1088 |
| m5.large | 2 | 8 | 0.124 |
同一のスペックだけど､t3.largeの方が僅かに安いですね｡なのでt3.largeを使おうと思った方!!
ちょっと待ってください!!
以下の条件全てに当てはまるなら､最初からT系インスタンスは使わないでください!
- 初めてAWSを使う
- 本番環境である
- 一般公開するシステムである(社内向けシステムではない)
また､いずれかに当てはまりT系インスタンスを検討されている方には必ずこのブログを読んで頂きたいです｡
このブログはAWS熟練者が本番環境や一般公開するシステムでT系インスタンスを使うことを否定するものではありません､あくまでもAWS初心者に向けた内容です｡
バースト可能パフォーマンスの選定
まずT系インスタンスはバースト可能パフォーマンスインスタンスと呼ばれます｡ AWSのドキュメントを確認して見ましょう｡
バースト可能パフォーマンスインスタンス T3および T2 インスタンスを含むバーストパフォーマンスインスタンスは、ベースラインレベルの CPU パフォーマンスを実現するとともに、ワークロードの必要に応じて高いレベルまでバーストする機能を実現できるように設計されています。バーストパフォーマンスインスタンスは、汎用アプリケーションの幅広い用途に適しています。たとえば、マイクロサービス、低レイテンシーのインタラクティブなアプリケーション、小中規模のデータベース、仮想デスクトップ、開発、ビルド & ステージング環境、コードリポジトリ、製品プロトタイプなどがあります。 バースト可能パフォーマンスインスタンス - Amazon Elastic Compute Cloud
ここで重要なのは､この一文です｡
ベースラインレベルの CPU パフォーマンスを実現する
T系インスタンスを使用する際は､求めるスペックに対してベースラインレベルがそれを満たしているか検討する必要があります｡
(例) t3.largeの場合
t3.largeのvCPUのベースラインパフォーマンスは30%である｡
vCPUが2つなので､乗算して30[%] * 2[vCPU] = 60[%]である｡
求めるスペックが合計CPU使用率､60%以下ならベースラインパフォーマンスに収まっている｡
ただしCloudWatch MetricsにはvCPU別で表示されるので､ベースラインパフォーマンスで動作するt3.largeのCPUUtilizationはは30%です｡
もし､vCPU別でCPUを常時40%使用する場合は､いずれCPUクレジットが枯渇してCPU使用率が30%に制限されます｡
CPUクレジット
1 個の CPU クレジットは、1 台の vCPU を使用率 100% で 1 分間実行することに相当します。その他の vCPU、使用率、時間数の組み合わせを CPU クレジットと同じにすることができます。たとえば、1 個の CPU クレジットは 1 台の vCPU を使用率 50% で 2 分間実行するか、または 2 台の vCPU を使用率 25% で 2 分間実行するのと等しくなります。 バースト可能パフォーマンスインスタンスの CPU クレジットおよびベースラインパフォーマンス - Amazon Elastic Compute Cloud
CPUクレジットは､バースト可能パフォーマンスインスタンスがCPUを使用する際に､必ず消費するリソースです｡EC2インスタンスが起動中ならば､当然CPUを使用するので起動中のインスタンスは常にCPUクレジット消費し続けています｡ 具体的にCPUクレジット当たり使用できるCPU時間は表の通りです｡CPUクレジット1個で1vCPUが1分間バースト(CPU使用率100%)できます｡
| CPUクレジット[個] | vCPU[個] | バースト時間[分] |
|---|---|---|
| 1 | 1 | 1 |
| 30 | 1 | 30 |
| 60 | 1 | 60 |
| 60 | 2 | 30 |
※バースト時間: 全てのvCPUの使用率100%で稼働し続ける事が可能な時間
消費するリソースという事はどこかから供給される必要があります｡インスタンスタイプ毎に､1時間あたりに受け取るCPUクレジットが決められています｡t3.largeの場合の表を記載します｡
| インスタンスタイプ | 1 時間あたりに受け取る CPU クレジット[個] | 蓄積可能な最大獲得クレジット[個] | vCPU | vCPU 別のベースラインパフォーマンス[%] | 最大バースト時間[時間] |
|---|---|---|---|---|---|
| A | B | C = B * 24[時間] | D | E = B / D / 60[分] * 100[%] | F = C / D / 60[分] |
| t3.large | 36 | 864 | 2 | 30 | 7.2 |
この､1 時間あたりに受け取る CPU クレジットが特に重要です｡これ以外の関連値は全て計算で導き出される値です｡ ここまで､インスタンスタイプ毎にベースラインパフォーマンスが定義されているかの様に記載してきました｡ですが､より正確には､ベースラインパフォーマンスはCPU クレジットの供給と消費が釣り合っている状態のCPU使用率です｡ なので､表に記載している計算で導く事が可能です｡ また､最大バースト時間(蓄積可能な最大獲得クレジットがチャージされている状態からバースト(CPU使用率100%)を続けられる時間)も計算で導き出せます｡バッチ処理などで一時的に使用する場合は､バースト前提で考えて処理が最大バースト時間に収まるかを検討して頂くと良いです｡
無制限モード
バースト可能パフォーマンスには 無制限モード という物があります｡これはCPUクレジットが枯渇した際に､未来24時間以内のCPUクレジットを先食い or 追加料金の支払いでCPUクレジットを得るモードです｡ t2インスタンスではデフォルト無効､t3インスタンスではデフォルト有効になっています｡この機能によって､24時間にわたるインスタンスのCPU使用率を平均化できるようになります。
無制限モードとして使用するCPUクレジットを CPU余剰クレジット(CPUSurplusCredit) と言います｡余剰クレジットを使用した場合は､その後CPUクレジットで返済できれば課金が発生しません｡ 課金が発生するのは以下の場合です｡
- 消費されたCPU余剰クレジットがインスタンスが24時間に獲得できる最大クレジット数を超えている
- インスタンスを停止または終了した
- インスタンスを
unlimitedからstandardに切り替えた
東京リージョン(ap-northeast-1)の場合､CPU余剰クレジットに対する課金は以下の通りです｡
Unlimited モードの T2 と T3 インスタンスの場合、CPU クレジットは次の通り請求されます。 Linux、RHEL、SLES の場合、vCPU 時間あたり 0.05 USD Windows および SQL Web を使用する Windows の場合、vCPU 時間あたり 0.096 USD オンデマンドインスタンスの料金 - Amazon EC2 (仮想サーバー) | AWS
無制限モードを考慮して､T3とM5の料金を比較してみましょう｡T3系でvCPU別の使用率が何%までならM5より安いか東京リージョンの場合で計算してみました｡
| インスタンスタイプ | A | t3.large | t3.xlarge | t3.2xlarge |
|---|---|---|---|---|
| vCPU[個] | B | 2 | 4 | 8 |
| T3の料金[USD/時間 ] | C | 0.1088 | 0.2176 | 0.4352 |
| M5の料金[USD/時間] | D | 0.124 | 0.248 | 0.496 |
| 料金差[USD] | E = D - C | 0.0152 | 0.0304 | 0.0608 |
| vCPU別のT3 ベースラインパフォーマンス[%] | F | 30% | 40% | 40% |
| 余剰クレジットに対するvCPU 時間あたりの料金[USD/時間] | G | 0.05 | 0.05 | 0.05 |
| vCPU時間(分)あたりの料金[USD/分] | H = G / 60 | 0.000833 | 0.000833 | 0.000833 |
| vCPU ごとに利用可能な追加のバースト[分] | I = E / H | 18.24 | 36.48 | 72.96 |
| 利用可能な追加 CPU [%] | J = (I / 60) / B | 15.20% | 15.20% | 15.20% |
| 損益分岐 CPU [%] | K = F + J | 45.20% | 55.20% | 55.20% |
.largeの場合だと､平均使用率が45.20%未満ならT3系の方が費用は安くなります｡
無制限モードの具体的な説明は下記のドキュメントにわかりやすくまとまっています｡ 例: 無制限モード - Amazon Elastic Compute Cloud
まとめ
冒頭で下記の条件に当てはまる方は最初からT系インスタンスを使わないでくださいと言いました､その理由を説明します｡
- 初めてAWSを使う
- 紹介したT系インスタンスの特性やCPUクレジットの話をおそらくご存知なかったですよね?
- 本番環境である
- 常にアクセスがありCPUリソースを使用し続けていますよね?
- 一般公開するシステムである(社内向けシステムではない)
- CPUクレジットの枯渇が発生して性能が制限された時に影響が大きいですよね?
こういった理由でした｡
AWSに慣れている方であれば､本番環境・一般公開するシステムであってもバースト可能インスタンスの特性を理解し､負荷試験の実施やCPUクレジットを適切に監視する事で問題なくシステムを動作させる事は可能です｡ しかし､それはワークロードがT系インスタンスにマッチしている場合で､どんなケースにおいてもT系が安いという事はありません｡ AWSのようなパブリッククラウドの素晴らしい所は､後からでもコンピューティングリソースを増減可能な事です｡まずは､M系でシステムを動かしてから平均CPU使用率を確認して可能ならT系インスタンスへの変更を検討されてはいかがでしょうか?
